背景提要

團隊走DevOps文化，所以頻繁地溝通理解，以及任何東西考慮對於系統的定位，已經是我們再熟悉不過的工作思維。

微服務化的系統，就我自己的解釋，會說每個部件專注在自己的業務，系統其他的部分會了解這個部件在做什麼，以及這個部件跟系統的關係和交互作用是什麼就好，但細節處理交給每個部件自己管理好。

人員的作業也是一樣，對自己負責的範圍專注且負責，同時了解系統其他的部分對自己守備的範圍有什麼交互作用，自己的東西調整或新增會影響系統的什麼，又或者別人守備的範圍調整的時候，主動思考自己的部分會被影響什麼。

那麼想要把ML的東西放入團隊的生態系，我們要怎麼將它擺到正確的位置呢？

讓成員有初步認識

首先，可以專心研究ML的人員，大概只佔不到團隊人數的1/5，這意味者大部分的人無法有多的時間持續吸收相關知識，而且我們都缺乏相關的背景。

專職的人員一樣負責掌握細節，但對於ML的定位和理解，是前所未有的經驗。

這個東西不是新的程式語言，也不是新的DB，或者另一種CI/CD自動化工具，或者類似目前系統的任何一個服務。

所以我們花了幾週的時間陸續討論和解釋，AI或者說ML大概能做到的事情，以及可能對於系統和商業能夠帶來什麼幫助。

最終至少大家大致明白了ML不是萬能的聖杯，想怎麼許願就怎麼許願，模型無法處理所有問題，而且非常多的局限性。

沒有錯誤的理解，就沒有錯誤的期待，而且模型出來的東西有一定的誤差，只能作為次要的輔助判斷，而非絕對的指示。

發揮想像力

當成員原本就知道自己產品的商業模式，又了解了ML的限制和提供的可能價值，大家就可以一起參與發想應用的方式，以及系統每個部分可以提供什麼協助。

ML的東西就不會被排除在外，反而受到我們原有的生態系統扶植，如果計畫能夠持續下去，相信經過時間的長，所能看到的效果越顯著。

另外或許訓練模型和統計資料分佈需要比較專精的知識和技能，但嘗試抓到重要的參數或因子關係，只需要眾人的觀察和想像，這個部分能夠越多的腦力支援越有幫助，尤其現在又有Vertex的幫助，收集新的參數有沒有發揮作用，Vertex自動化的判斷會告訴我們，我們只需要更多的嘗試。

能夠快速的迭代，從錯誤中尋找價值，給予我們這種ML外行團隊很大的幫助，以及建立一種有效的經驗學習方式。

工作協助

在大家逐漸認識到資料收集和處理的複雜和重要性，這部分很多人就可以幫忙協助，因為對於後端工程師，無時無刻都在處理資料，我們已經有許多處理資料的經驗，現在只是想要交給ML，嘗試將資料進一步的應用。

所以與其說是跨足新的項目，我會說對於原本的工程師團隊，不如想作是價值的延伸，既然是整體價值的延伸，我們就更有共識地同進同退。

當模型完成後，團隊對於服務與系統Ops(部署、維運、管理)的流程也是熟門熟路，除了選擇Google提供的課金代管服務，這部分又可以另外選擇交給其他成員幫忙，讓探索ML的人員專注在研究資料與模型的處理上。

這又回到專注業務細節，又能夠交融於系統的基礎上。

結語

雖然沒有經驗豐富的成員在前面拉拔著前進，但本質上我們也不會因為踏入AI的失敗，而讓部門會有績效上的壓力(感謝成員們工作的cover)，原本的任務還是持續進行著，大家也因為理解這是不確定的東西，沒有一定會有效果的成見。

這兩年Google也提出了新名詞MLOps，描述了用商業應用的角度去看，ML code其實只是其中的一部分，要有相關的operation流程才算完整。

或許相比有的團隊擁有ML knowledge，但是Ops相對辛苦，我們則是擁有Ops的基礎，相對缺少的是ML knowlege，也就是說至少環境條件不算差，希望能夠繼續走下去。